iverilogfandomcom-20200214-history
Introduction
This chapter summarizes the place of the Verilog hardware description language in the greater task of digital electronics design. The details of the steps from algorithm to implementation vary amongst the suppliers of design tools and the physical technologies of the final product, but Verilog has a place regardless. We also review some terminology that's commonly used but not always clearly defined. The rest of this documentation uses some of these common words, such as "synthesis" and "netlist", in specific, meaningful ways. Their use hopefully matches common use in the work place, so this should not confuse the reader. The Design Process In General Hardware design starts with an abstract description of the intended device--the design. The designer enters that design using design entry languages such as schematic drawings and hardware description languages. The designer then verifies that the design is correct by simulating the entered design. Once the designer is satisfied that the design functions properly, he directs the computer to synthesize a specially formatted file, a netlist, that describes a real circuit that behaves as the simulation. The netlist is then used to direct physical implementation tools. The synthesized netlist is used as input to the tools that build the final device. These physical implementation tools usually include some sort of floor planning software to arrange the primitives of the technology on the die. The set of primitives available to the netlist may be defined by the physical implementation tools themselves, but ultimately reflect the physical realities of the target technology, whether a VLSI integrated circuit chip or a reprogrammable gate array. The physical implementation tools create a layout that arranges the primitives on the die or gate array. Because of the high fixed costs of chip fabrication, VLSI designers typically put the synthesized netlist and layout through an extra battery of tests to verify correct behavior. These tests may include timing simulations and power consumption calculations. The layout may require considerable change before it is finally shown to behave like the synthesized netlist, and the original design, within the planned constraints of power consumption and speed. FPGA floor planners have an easier task because the components of a gate array have relatively simple and predictable behavior, without significant analog effects. The place and route process assigns primitives of the netlist to resources of the gate array (the primitives are placed) and connects them together via wires available on the chip (the design is routed). Unlike for VLSI designs, place and route for FPGAs may place primitive components and expect them to operate within predefined limits. Verilog in the Design Process A Verilog program for simulation is often divided into two major parts: the device under test and the test bench. The test bench is mostly Verilog code that stimulates the device under test and observes the behavior of the simulation. The device under test is a Verilog module that represents the entire device being designed and tested. A Verilog program for synthesis does not include the test bench needed in a program for simulation. A program intended for synthesis may even be compiled by a different Verilog compiler, one optimized for efficient synthesis and incapable of simulation. A Verilog programmer, therefore, may prefer to write Verilog for the device under test as if intended for synthesis, and carefully separate the test bench code into different source code files and modules. Verilog synthesizers understand a subset of the Verilog language that they transform into a netlist for physical implementation. The documentation for a specific synthesizer should describe the subset of Verilog that it accepts, and also should describe any technology specific aspects of synthesis that it supports. Verilog simulators, on the other hand, are expected to understand the entire Verilog language. They need not attempt to generate netlists for physical implementation, they just need to simulate the description according to the rules of the Verilog language. This allows the programmer to write test bench code, never intended for physical implementation, to simulate the operating conditions of the device under test. Icarus Verilog in the Design Process Icarus Verilog does the practical work of using Verilog; it collects all the written source code of the Verilog design, checks for coding errors and writes compiled design files. It helps access source files collected into libraries, link together modules spread throughout source files, and write compiled results. Icarus Verilog is intended to work mainly as a simulator, although its synthesis capabilities are improving. The Icarus Verilog compiler normally compiles a Verilog program into an executable file that can be run to perform the actual simulation. It also includes software that runs the compiled simulation and generates the text or waveform outputs requested by the programmer. In addition to the default simulation format, Icarus Verilog can generate various external netlist formats. When generating netlists, the compiler needs to know the syntax of the netlist file and the primitives of the target technology or device. Target formats must be more specific than merely a netlist format. For example, it is not enough to request an EDIF netlist; the code generator needs to know which primitives can be included in the netlist. Therefore, Icarus Verilog includes an extendable code generator interface that can be used to attach new output formatters to the compiler.